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1.0  INTRODUCTION 


The  complex  challenges  posed  by  the  future  security  environment  calls  for  a  systematic  method  for 
planning  under  uncertainty  with  the  aim  of  providing  the  capabilities  required  to  achieve  the  range  of 
objectives/effects  needed  to  successfully  accomplish  NATO’s  missions  and  aims.  This  capability  based 
planning  needs  to  be  enhanced  and  applied  more  widely  within  NATO  Defence  Planning  (DP). 
Furthermore,  capability  requirements  should  be  identified  in  a  manner  that  is  traceable  and  transparent  and 
one  that  facilitates  the  timely  and  efficient  development  of  solutions  to  meet  these  requirements. 

Addressing  these  challenges  will  also  require  a  Comprehensive  Approach  focussed  on  the  achievement  of 
objectives/effects  through  a  coordinated  use  of  the  Alliance’s  Political,  Military,  Economic  and  Civil 
instruments  of  power.  It  will  also  often  require  the  Alliance  to  operate  as  part  of  a  wider  Coalition. 
Consequently,  achieving  the  required  objective/effects  will  often  necessitate  the  coordinated  action  of 
many  disparate  entities  within  and  between  organizations.  These  organizations  may  be  military  and  non¬ 
military.  They  may  be  NATO  organizations  or  organizations  from  member  nations.  They  may  also  be 
organizations  from  non-NATO  nations,  International  Organizations  (IO)  such  as  the  UN  and  Non- 
Governmental  Organizations  (NGO).  Coordinated  action  will  require  effective  Command  and  Control 
(C2),  Intelligence,  Surveillance  and  Reconnaissance  (ISR)  and  interoperability  between  the  entities 
involved  in  C2  and  ISR  will  be  critical.  This  in  turn  will  require  timely  exchange  of  relevant  information. 
A  structured,  systematic  method  to  defining  this  information  sharing  is  critical. 

The  complexity  and  uncertainty  outlined  above  means  that  interoperability  will  often  need  to  be  achieved 
on  an  ad-hoc  basis.  The  manner  in  which  interoperability  is  achieved  therefore  needs  to  be  flexible  and 
adaptive.  Such  flexibility  and  adaptability  is  achieved  by  applying  a  service  oriented  approach  to 
developing  solutions  to  interoperability  at  the  organizational  and  system  level. 

The  key  to  deriving  robust  C2  and  ISR  capabilities  and  associated  interoperability  is  to  separate  ‘what 
needs  to  be  delivered’  (i.e.,  the  capability  requirements)  from  ‘how  it  is  delivered’  (the 
solution/technology).  To  do  this  one  needs  to  introduce  the  concept  of  ‘service1  provision’.  This  entails 
specifying  the  ‘requester’  for  a  task  to  be  performed  and  a  ‘provider’  who  commits  to  performing  the  task. 
An  example  of  a  requester  may  be  a  HQ  and  the  provider  may  be  a  subordinate  unit  or  another  HQ.  This 
illustrates  that  a  request  may  be  a  tasking  with  an  obligation  to  deliver,  or  a  request  that  can  be  negotiated 
and  potentially  denied.  This  is  the  essence  of  the  service  oriented  approach. 

The  service  oriented  approach  is  a  natural  complement  to  capability  based  planning.  Furthermore  the 
service  oriented  approach  emphasizes  the  description  of  how  the  elements  within  a  system/organization 
interrelate  and  interact  to  perform  tasks  and  hence  achieve  required  objectives  and  effects.  Such 
interrelation  and  interaction  is  the  core  element  of  architecture  definition.  The  generation  of  architectures 
is  therefore  intrinsic  to  this  service  orientated  approach. 


Service:  A  type  of  delivered  functionality,  specified  independently  of  the  capabilities  that  provide  it  (NAF  v3.0). 
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This  paper  outlines  how  a  service  oriented  approach  could  be  applied  to  support  the  generation  of  C2  and 
ISR  capabilities  and  associated  interoperability  in  the  context  of  the  NATO  Defence  Planning  Process 
(NDPP).  This  results  in  a  clear,  auditable  trail  from  the  strategic  missions  that  NATO  must  be  able  to 
undertake  through  to  the  C2  and  ISR  capabilities  needed  to  perform  these  missions.  The  approach 
provides  a  systematic  way  for  deriving  a  comprehensive  set  of  requirements,  is  scalable  and  adjustable  to 
the  problem  at  hand,  and  has  broad  applicability.  Its  application  entails  the  collaboration  of  different 
stakeholders  from  the  operational  and  technical  community. 

1.1  The  Methodology 

The  methodology  for  derivation  of  C2  and  ISR  requirements  is  outlined  in  the  following  figure  and 
containing  6  basic  steps. 


^  .  .  Operations 

Guidance 

Doctrine/Policy, 

Previous 

Concepts  for  ops. 

studies 

What  do 
we  need 
to  do 


1 )  Identify  operational 
context 


How 
could  we 
do  it 


3)  Design  operational 
activities 


With  what 


5)  Identify  user 


information  services 


2)  Define  operational 
activities 


4)  Determine 
collaboration  between 
solution  elements 


6)  Identify  NNEC 
technical  services 


1.  Identify  operational  context:  The  aim  in  this  step  is  to  describe  the  operational  context  and 
the  set  of  tasks  (operational  activities)  relating  to  planning,  execution  and  assessment  that  need 
to  be  undertaken  within  a  Mission  Type  (MT).  The  NATO  MTs  and  associated  Planning 
Situations  used  in  Defence  Planning  provide  the  basis  for  describing  the  operational  context. 
The  operational  context  includes  operational  activities  that  need  to  be  performed  in  order  to 
accomplish  the  Mission,  the  operational  activities  require  a  ‘requester’  and  ‘provider’.  The 
Defence  Planning  Mission  Task  Decomposition  (MTD)  provides  the  basis  for  identifying  the 
operational  activities. 

2.  Define  operational  activities:  The  aim  of  this  step  is  to  further  develop  the  operational 
activities  identified  in  step  1  by  defining  the  objective/effect  to  be  achieved,  conditions  and 
constraints  on  achieving  the  objective/effect  and  the  required  Quality  of  Operation  (QoO). 
QoO  is  a  collection  of  operational  attributes  concerned  with  how  well  (performance  metrics) 
the  operational  activity  needs  to  be  performed.  Requirements  are  stated  in  a  solution 
independent  manner. 

3.  Design  operational  activity:  In  this  step  different  solutions  are  designed/analyzed  in  order  to 
identify  which  of  them  meets  the  requirements  established  in  the  previous  step.  The  design  is 
based  on  solution  elements  (e.g.,  HQ,  Air/Land/Maritime  units  and  non-military  elements)  and 
specifies  their  functions  and  how  they  generally  need  to  interact.  Depending  on  the  nature  of 
the  problem  and  the  time  horizon  under  consideration,  solution  elements  may  be  highly 
specific  (e.g.,  specific  system)  or  more  generic.  These  solution  elements  will  ultimately  be 
provided  by  Alliance  member  nations  or  NATO. 
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4.  Determine  collaboration  between  solution  elements:  This  step  determines  how  the  solution 
elements  identified  in  step  3  collaborate  and  identifies  the  classes  of  information  products  that 
each  solution  element  needs  to  produce  and  utilize  to  enable  such  collaboration. 

5.  Define  User  Information  Services:  “User  Information  Service  (UIS)”  is  the  delivery  of 
information  to  a  user  in  order  to  fulfil  that  user’s  information  requirements.  The  aim  of  this 
step  is  to  identify  the  UISs  that  each  solution  element  identified  in  step  4  must  provide,  such 
that  the  operational  activities  identified  in  step  1  can  be  provided.  The  specific  information 
products  required  to  enable  the  collaboration  identified  in  step  4  are  identified  for  each  solution 
element. 

6.  Define  NNEC  Technical  Services:  The  NNEC  Technical  Services  (NTS)  captures  which 
technical  services  need  to  be  implemented  in  order  to  support  the  UISs  identified  in  step  5. 
Standards  from  NATO  and  civilian  standardization  organizations  should,  to  the  maximum 
extent  be  used. 

1.2  Use  of  Architectures 

Information  generated  or  identified  by  applying  the  methodology  populates  architectures  as  appropriate. 
As  noted  earlier  architectures  describe  how  elements  within  a  system/organization  interrelate  and  interact 
and  can  therefore  be  used  to  link  in  a  readily  understandable,  transparent  and  traceable  manner, 
operational  activities  identified  in  step  1  to  NNEC  Technical  Services  (NTS)  identified  in  step  6.  The 
NATO  Architecture  Framework  (NAF)  v3.0  identifies  a  total  of  7  different  types  of  views,  each  consisting 
of  a  set  of  sub-views  that  can  be  used  to  present  (communicate)  the  information  generated  by  applying  the 
methodology: 

•  NATO  All  View; 

•  NATO  Capability  View; 

•  NATO  Operational  View; 

•  NATO  Service  Oriented  View; 

•  NATO  Systems  View; 

•  NATO  Technical  View; 

•  NATO  Programme  View. 

The  figure  below  shows  how  various  architecture  views  map  onto  the  sub-processes  in  the  NDPP.  These 
architectural  views  support  the  development  of  capabilities,  interoperability,  NNEC  implementation  and 
documentation. 
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In  order  to  be  able  to  effectively  share  the  architecture  data,  the  architecture  data  needs  to  be  stored  in  the 
NATO  Architecture  Repository  (NAR)  following  an  agreed  set  of  ‘rules’  as  laid  out  in  the  NATO  Meta 
Model  (NMM)2.  The  architecture  views  can  then  be  generated  and  communicated  as  required. 
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1.3  Summary/Conclusion 

Applying  the  methodology  outlined  in  this  paper  ensures  that  a  consistent  operational  context  is  used  for 
C2  and  ISR  capability  development.  The  methodology  will  support  the  NDPP  in  generating  a  consistent 
set  of  C2  and  ISR  related  NATO  Defence  Planning  Targets  for  both  NATO  and  member  nations,  and 
hence  will  support  interoperability. 


2 

Described  in  the  NAF. 
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